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REMARKS 

This Amendment is filed in response to the Response to Amendment mailed April 
21 , 2006, the Advisory Action mailed Dec. 15, 2005, and the Final Office Action mailed 
Aug, 26, 2005, and supplements the Amendment mailed Jan. 26, 2006. All standing ob- 
jections and rejections are respectfully traversed. 

Claims 1-4, 9-19, and 22-49 are now pending in the case. 

Claims 17, 22, 29, 34 have been amended to better claim the invention. 

Claims 20 and 21 have been cancelled. 

No claims have been added. 

In the Response to Amendment mailed April 21, 2006, the Examiner requested 
arguments relating to independent claims 22, 26 and 29. Accordingly, the Applicant in 
this Supplemental Amendment addresses these claims and discusses the cited prior art 
references. 

Claim Rejections - 35 U.S.C. 103 

At paragraph 1 of the Final Office Action, claims 1-3 and 9-19 were rejected un- 
der 35 U.S.C. § 103(a) as unpatentable over Martin, U.S. Patent No. 5,765,927 (hereinaf- 
ter Martin), in view of Real-Time Streaming Protocol (RTSP), Internet Engineering Task 
Force Request for Comment 2326 (hereinafter RFC 2326). 

The Applicant addressed this rejection at length in the Amendment mailed Jan. 
26, 2006. Accordingly, the Applicant respectfully refers the Examiner to that Amend- 
ment for a detailed discussion of why these claims are allowable. 
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At paragraph 2 of the Final Office Action, claim 4 was rejected under 35 U.S.C. 
§ 103(a) as unpatentable over Martin, in view of Resource ReSerVation Protocol (RSVP), 
Internet Engineering Task Force Request for Comment 2205 (hereinafter RFC 2205). 

The Applicant notes that claim 4 is a dependent claim that depends from an inde- 
pendent claim that is believed to be allowable for the above described reasons. Accord- 
ingly, claim 4 is also believed to be allowable. 

At paragraph 3 of the Final Office Action, claims 17-19 were rejected under 35 
U.S.C. § 103(a) as unpatentable over Martin, U.S. Patent No. 5,765,927 (hereinafter Mar- 
tin), in view of Format of the RSVP DCLASS Object, Request for Comment 2996 (here- 
inafter RFC 2996). 

The Applicant's claim 17, representative in part of the other rejected claims, sets 

forth: 

17. An intermediate network device for use within a computer 
network having a server configured to provide one or more data streams to 
a client, each stream having a corresponding bandwidth, the intermediate 
network device comprising: 

means for determining traffic characteristics sufficient to identify a 
stream from the server to the client; 

means for intercepting RTSP Describe Response messages sent 
from the server to the client and for determining the bandwidth of the 
stream from a field of the RTSP Describe Response messages; 

a resource reservation protocol (RSVP) transmitter proxy config- 
ured to reserve resources within the computer network on behalf of the 
server for allocation to the stream and to generate and send one of more 
RSVP Path messages on behalf of the server, the one or more RSVP Path 
messages containing the network traffic characteristics and the bandwidth 
of the stream; and 

means for obtaining a differentiated services codepoint (DSCP) 
value that is based on the bandwidth of the stream. 
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In relevant part, Martin discloses a host proxy service for extending RSVP- 
signaled Quality of Service to flows involving hosts that are not RSVP aware. See col. 1 , 
lines 55-57. As part of this process, Martin's network device determines characteristics 
for the flow from an RSVP messages that "includes an RSVP common header identifying 
the message as a Path message and an RSVP object including the contents of the Path 
message. The contents of the Path message include a Sender TSPEC describing the flow 
that the sender expects to generate and an ADSPEC." See col. 4 line67 to col. 5, line 5. 
Indeed the TSPEC 

RFC 2996 describes using a resource Reservation Protocol to handle a request for 
Quality of Service in a differentiated service (DS) network. Using RSVP with a DS net- 
work allows the RSVP message to carry Differential Service Code Points (DSCPs). 

The Applicant respectfully urges that the combination of Martin and RFC 2996 
teaches away from the Applicants "means for intercepting RTSP Describe Response 
messages sent from the server to the client and for determining the bandwidth of the 
stream from a field of the RTSP Describe Response messages" when considered in the 
context of the rest of the Applicant's claimed elements. 

Specifically, one following the teachings of Martin and RFC 2996 would be led to 
construct an intermediate host proxy device that determines bandwidth of the stream us- 
ing functionality provided in RSVP. That is, the device would examine RSVP fields 
such as the TSPEC field. Nothing in these references suggests that RTSP should be used 
in conjunction with RSVP for determining bandwidth. Indeed, neither reference even 
mentions RTSP. Accordingly, following the teachings of the references, one would be 
led astray from intercepting RTSP Describe Response messages sent from the server to 
the client and determining the bandwidth of the stream from a field of the RTSP De- 
scribe Response messages, and instead would look to RSVP for mechanisms to deter- 
mine bandwidth. 

Accordingly, the Applicant respectfully urges that Martin and RFC 2996 are le- 
gally insufficient to make obvious the present claims under 35 U.S.C. §103, because of 
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the absence of the Applicant's claimed novel "means for intercepting RTSP Describe 
Response messages sent from the server to the client and for determining the band- 
width of the stream from a field of the RTSP Describe Response messages" when con- 
sidered in the context of the rest of the Applicant's claimed elements. 



At paragraph 4 of the Final Office Action, claims 20-25, 27, 29-32 and 34 were 
rejected under 35 U.S.C. § 103(a) as obvious in view of Martin and Merwe et aL, 
Mmdump: A tool for Monitoring Internet Multimedia Traffic (hereinafter Merwe). 



22. A method for operating a router, comprising: 

receiving a Real Time Streaming Protocol (RTSP) message from a 
client, the message directed to a server, the client message requesting that 
the server begin sending a traffic flow to the client; 

receiving a RTSP response message from the server, the response 
message responding to the message from the client; 

examining the RTSP response message to determine a bandwidth 
for the traffic flow to the client; 

transmitting, in response to the RTSP response message, a re- 
source reservation request message (RSVP request message) to the cli- 
ent, the RSVP message establishing a path to the client; 

receiving a RSVP Resv message from the client, the RSVP Resv 
message reserving resources for the requested traffic flow; 

receiving a data message of the traffic flow from the server; and 

transmitting the data message of the traffic flow with a resource 
reservation indicia in the data message, the resource reservation indicia to 
direct the data message to travel along the reserved resources. 

Martin is described above. 

Merwe describes a network monitor tool for monitoring packets of multimedia 
traffic and storing (i.e. "dumping") packets that meet certain criteria into a file for later 
analysis. See Section 3. The tool supports Real Time Streaming Protocol (RTSP). See 
Section 2.2. As part of RTSP, a client issues a DESCRIBE request for a media stream it 
is interested in. A server then responds with a response containing media specific infor- 
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mation about the stream, such as the encoding used, the clip length, average bit rate, etc. 
See Section 2.2. 

The Applicant respectfully urges that the combination of Martin and Merwe does 
not suggest the Applicant's claimed "a router.. ..receiving a RTSP response message 
from the server, the response message responding to the message from the client; ex- 
amining the RTSP response message to determine a bandwidth for the traffic flow to 
the client; transmitting, in response to the RTSP response message, a resource reserva- 
tion request message (RSVP request message) to the client" 

As described above, Martin is completely silent concerning RTSP, but rather sug- 
gests one should rely only upon the functionality of RSVP. While Merwe does discuss 
the use of RTSP, combining Merwe with Martin still does not show the Applicant's 
claims. Merwe simply describes the basic functionality of RTSP and that it may be used 
with streaming multimedia. There is no suggestion that a router should examine a RTSP 
response message to determine a bandwidth for the traffic flow to the client, and in re- 
sponse to the RTSP response message transmit a resource reservation request message 
(RSVP request message) to the client. That is, the interaction between the two proto- 
cols is entirely absent from either of the references. 

Tellingly, Martin lacks any mention of RTSP and Merwe lacks any mention ot 
RSVP. Thus even if the references are combined, there is still no suggestion of transmit- 
ting, in response to the RTSP response message* a resource reservation request mes- 
sage (RSVP request message) to the client. 

Accordingly, the Applicant respectfully urges that Martin and Merwe are legally 
insufficient to make obvious the present claims under 35 U.S.C. §103 because of the ab- 
sence of the Applicant's claimed novel "a router.... receiving a RTSP response message 
from the server, the response message responding to the message from the client; ex- 
amining the RTSP response message to determine a bandwidth for the traffic flow to 
the client; transmitting, in response to the RTSP response message, a resource reserva- 
tion request message (RSVP request message) to the client." 
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At paragraph 5 of the Final Office Action, claims 28 and 35 were rejected under 
35 U.S.C. §103(a) as unpatentable over Martin in view of Merwe in further view of Gai 
et al., RSVP Proxy - Internet Draft (hereinafter Gia). 

Claims 28 and 35 are dependent claims that depend from independent claims that 
are believed to be allowable for the above described reasons. Accordingly, claims 28 and 
35 are also believed to be allowable. 

Allowable Subject Matter 

At page 12 of the Final Office Action, claims 26 and 33 where indicated to be al- 
lowable if rewritten in independent form. In accord with the Examiner's suggestion, the 
Applicant rewrote these claims in independent form and the claims were allowed in the 
Advisory Action of Dec. 15, 2005. Subsequently, the Applicant noticed that the ordering 
of elements of in the claims, and other artifacts introduced by combining the independent 
claims and the dependent claims, made the claims difficult to follow and unclear. The 
Applicant has therefore reordered some of the claim elements and made other nominal 
corrections to improve clarity. Such changes are not believed to affect the allowability of 
the claims, as they simply improve clarity. Accordingly, the Applicant respectfully re- 
quests the allowability of these claims be maintained. 

New Claims 

In light of the Examiner's allowance of claims 26 and 33, the Applicant has added 
new claims 36-49 that particularly claim that the router snoops a second message from 
the server, sent in response to a first message from the client, in order to determine band- 
width. Such claims are believed to be allowable in light of the Examiner's allowance of 
claims 26 and 33. 



18 



1 



PATENTS 
112025-0430 
CPOL# 80941 Seq.# 2954 



In the event that the Examiner deems personal contact desirable in disposition of 
this case, the Examiner is encouraged to call the undersigned attorney at (617) 951-2500. 

All independent claims are believed to be in condition for allowance. 

All dependent claims are believed to be dependent from allowable independent 

claims. 

The Applicant respectfully solicits favorable action. 

Please charge any additional fee occasioned by this paper to our Deposit Account 



No. 03-1237. 



Respectfully submitted, 




Reg. No. 51,477 

CESARI AND MCKENNA, LLP 
88 Black Falcon Avenue 
Boston, MA 02210-2414 
(617)951-2500 
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